home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / rfc / rfc1347 < prev    next >
Text File  |  1992-06-17  |  27KB  |  562 lines
  1.  
  2.  
  3.  
  4.         Network Working Group                                  Ross Callon
  5.         Request for Comments: 1347                                     DEC
  6.                                                                  June 1992
  7.  
  8.  
  9.  
  10.                     TCP and UDP with Bigger Addresses (TUBA),
  11.               A Simple Proposal for Internet Addressing and Routing
  12.  
  13.  
  14.  
  15.         Status of the Memo
  16.  
  17.         This memo provides information for the Internet community. It
  18.         does not specify an Internet standard. Distribution of this
  19.         memo is unlimited.
  20.  
  21.  
  22.         1 Summary
  23.  
  24.         The Internet is approaching a situation in which the current IP
  25.         address space is no longer adequate for global addressing
  26.         and routing. This is causing problems including: (i) Internet
  27.         backbones and regionals are suffering from the need to maintain
  28.         large amounts of routing information which is growing rapidly in
  29.         size (approximately doubling each year); (ii) The Internet is
  30.         running out of IP network numbers to assign. There is an urgent
  31.         need to develop and deploy an approach to addressing and routing
  32.         which solves these problems and allows scaling to several orders
  33.         of magnitude larger than the existing Internet. However, it is
  34.         necessary for any change to be deployed in an incremental manner,
  35.         allowing graceful transition from the current Internet without
  36.         disruption of service. [1]
  37.  
  38.         This paper describes a simple proposal which provides a long-term
  39.         solution to Internet addressing, routing, and scaling. This
  40.         involves a gradual migration from the current Internet Suite
  41.         (which is based on Internet applications, running over TCP or
  42.         UDP, running over IP) to an updated suite (based on the same
  43.         Internet applications, running over TCP or UDP, running over CLNP
  44.         [2]). This approach is known as "TUBA" (TCP & UDP with Bigger
  45.         Addresses).
  46.  
  47.         This paper describes a proposal for how transition may be
  48.         accomplished. Description of the manner in which use of CLNP,
  49.         NSAP addresses, and related network/Internet layer protocols
  50.         (ES-IS, IS-IS, and IDRP) allow scaling to a very large ubiquitous
  51.         worldwide Internet is outside of the scope of this paper.
  52.  
  53.         Originally, it was thought that any practical proposal needed to
  54.         address the immediate short-term problem of routing information
  55.         explosion (in addition to the long-term problem of scaling to a
  56.         worldwide Internet). Given the current problems caused by
  57.         excessive routing information in IP backbones, this could require
  58.         older IP-based systems to talk to other older IP-based systems
  59.         over intervening Internet backbones which did not support IP.
  60.         This in turn would require either translation of IP packets into
  61.  
  62.  
  63.         Callon                                                    [Page 1]
  64.  
  65.  
  66.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  67.  
  68.  
  69.         CLNP packets and vice versa, or encapsulation of IP packets
  70.         inside CLNP packets. However, other shorter-term techniques (for
  71.         example [3]) have been proposed which will allow the Internet to
  72.         operate successfully for several years using the current IP
  73.         address space. This in turn allows more time for IP-to-CLNP
  74.         migration, which in turn allows for a much simpler migration
  75.         technique.
  76.  
  77.         The TUBA proposal therefore makes use of a simple long-term
  78.         migration proposal based on a gradual update of Internet Hosts
  79.         (to run Internet applications over CLNP) and DNS servers (to
  80.         return larger addresses). This proposal requires routers to be
  81.         updated to support forwarding of CLNP (in addition to IP).
  82.         However, this proposal does not require encapsulation nor
  83.         translation of packets nor address mapping. IP addresses and NSAP
  84.         addresses may be assigned and used independently during the
  85.         migration period. Routing and forwarding of IP and CLNP packets
  86.         may be done independently.
  87.  
  88.         This paper provides a draft overview of TUBA. The detailed
  89.         operation of TUBA has been left for further study.
  90.  
  91.  
  92.         2 Long-Term Goal of TUBA
  93.  
  94.         This proposal seeks to take advantage of the success of the
  95.         Internet Suite, the greatest part of which is probably the use of
  96.         IP itself. IP offers a ubiquitous network service, based on
  97.         datagram (connectionless) operation, and on globally significant
  98.         IP addresses which are structured to aid routing. Unfortunately,
  99.         the limited 32-bit IP address is gradually becoming inadequate
  100.         for routing and addressing in a global Internet. Scaling to the
  101.         anticipated future size of the worldwide Internet requires much
  102.         larger addresses allowing a multi-level hierarchical address
  103.         assignment.
  104.  
  105.         If we had the luxury of starting over from scratch, most likely
  106.         we would base the Internet on a new datagram internet protocol
  107.         with much larger multi-level addresses. In principle, there are
  108.         many choices available for a new datagram internet protocol. For
  109.         example, the current IP could be augmented by addition of larger
  110.         addresses, or a new protocol could be developed. However, the
  111.         development, standardization, implementation, testing, debugging
  112.         and deployment  of a new protocol (as well as associated routing
  113.         and host-to-router protocols) would take a very large amount of
  114.         time and energy, and is not guaranteed to lead to success. In
  115.         addition, there is already such a protocol available. In
  116.         particular, the ConnectionLess Network Protocol (CLNP [1]) is
  117.         very similar to IP, and offers the required datagram service and
  118.         address flexibility. CLNP is currently being deployed in the
  119.         Internet backbones and regionals, and is available in vendor
  120.         products. This proposal does not actually require use of CLNP
  121.         (the main content of this proposal is a graceful migration path
  122.         from the current IP to a new IP offering a larger address space),
  123.  
  124.  
  125.         Callon                                                    [Page 2]
  126.  
  127.  
  128.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  129.  
  130.  
  131.         but use of CLNP will be assumed.
  132.  
  133.         This proposal seeks to minimize the risk associated with
  134.         migration to a new IP address space. In addition, this proposal
  135.         is motivated by the requirement to allow the Internet to scale,
  136.         which implies use of Internet applications in a very large
  137.         ubiquitous worldwide Internet. It is therefore proposed that
  138.         existing Internet transport and application protocols continue to
  139.         operate unchanged, except for the replacement of 32-bit IP
  140.         addresses with larger addresses. The use of larger addresses will
  141.         have some effect on applications, particularly on the Domain Name
  142.         Service. TUBA does not mean having to move over to OSI
  143.         completely. It would mean only replacing IP with CLNP. TCP, UDP,
  144.         and the traditional TCP/IP applications would run on top of CLNP.
  145.  
  146.         The long term goal of the TUBA proposal involves transition to a
  147.         worldwide Internet which operates much as the current Internet,
  148.         but with CLNP replacing IP and with NSAP addresses replacing IP
  149.         addresses. Operation of this updated protocol suite will be very
  150.         similar to the current operation. For example, in order to
  151.         initiate communication with another host, a host will obtain a
  152.         internet address in the same manner that it normally does, except
  153.         that the address would be larger. In many or most cases, this
  154.         implies that the host would contact the DNS server, obtain a
  155.         mapping from the known DNS name to an internet address, and send
  156.         application packets encapsulated in TCP or UDP, which are in turn
  157.         encapsulated in CLNP. This long term goal requires a
  158.         specification for how TCP and UDP are run over CLNP. Similarly,
  159.         DNS servers need to be updated to deal with NSAP addresses, and
  160.         routers need to be updated to forward CLNP packets. This proposal
  161.         does not involve any wider-spread migration to OSI protocols.
  162.  
  163.         TUBA does not actually depend upon DNS for its operation. Any
  164.         method that is used for obtaining Internet addresses may be
  165.         updated to be able to return larger (NSAP) addresses, and then
  166.         can be used with TUBA.
  167.  
  168.  
  169.         3 Migration
  170.  
  171.         Figure 1 illustrates the basic operation of TUBA. Illustrated is
  172.         a single Internet Routing Domain, which is also interconnected
  173.         with Internet backbones and/or regionals. Illustrated are two 
  174.         "updated" Internet Hosts N1 and N2, as well as two older hosts H1
  175.         and H2, plus a DNS server and two border routers. It is assumed
  176.         that the routers internal to the routing domain are capable of
  177.         forwarding both IP and CLNP traffic (this could be done either by
  178.         using multi-protocol routers which can forward both protocol
  179.         suites, or by using a different set of routers for each suite).
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.         Callon                                                    [Page 3]
  188.  
  189.  
  190.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  191.  
  192.  
  193.  
  194.  
  195.                          ................    ................
  196.                          .    H1        .    .  Internet    .
  197.                          .              .-R1-.              .
  198.                          .  H2          .    .  Backbones   .
  199.                          .        DNS   .    .              .
  200.                          .              .    .     and      .
  201.                          .      N1      .    .              .
  202.                          .              .    .  Regionals   .
  203.                          .          N2  .-R2-.              .
  204.                          ................    ................
  205.  
  206.                            Key
  207.  
  208.                       DNS    DNS server
  209.                        H     IP host
  210.                        N     Updated Internet host
  211.                        R     Border Router
  212.  
  213.                             Figure 1 - Overview of TUBA
  214.   
  215.  
  216.  
  217.         Updated Internet hosts talk to old Internet hosts using the
  218.         current Internet suite unchanged. Updated Internet hosts talk to
  219.         other updated Internet hosts using (TCP or UDP over) CLNP. This
  220.         implies that updated Internet hosts must be able to send either
  221.         old-style packets (using IP), or new style packet (using CLNP).
  222.         Which to send is determined via the normal name-to-address
  223.         lookup.
  224.  
  225.         Thus, suppose that host N1 wants to communicate with host H1. In
  226.         this case, N1 asks its local DNS server for the address
  227.         associated with H1. In this case, since H1 is a older
  228.         (not-updated) host, the address available for H1 is an IP
  229.         address, and thus the DNS response returned to N1 specifies an IP
  230.         address. This allows N1 to know that it needs to send a normal
  231.         old-style Internet suite packet (encapsulated in IP) to H1.
  232.  
  233.         Suppose that host N1 wants to communicate with host N2. In this
  234.         case, again N1 contacts the DNS server. If the routers in the
  235.         domain have not been updated (to forward CLNP), or if the DNS
  236.         resource record for N2 has not been updated, then the DNS server
  237.         will respond with a normal IP address, and the communication
  238.         between N1 and N2 will use IP (updated hosts in environments
  239.         where the local routers do not handle CLNP are discussed in
  240.         section 6.3). However, assuming that the routers in the domain
  241.         have been updated (to forward CLNP), that the DNS server has been
  242.         updated (to be able to return NSAP addresses), and that the
  243.         appropriate resource records for NSAP addresses have been
  244.         configured into the DNS server, then the DNS server will respond
  245.         to N1 with the NSAP address for N2, allowing N1 to know to use
  246.  
  247.  
  248.  
  249.         Callon                                                    [Page 4]
  250.  
  251.  
  252.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  253.  
  254.  
  255.         CLNP (instead of IP) for communication with N2.
  256.  
  257.         A new resource record type will be defined for NSAP addresses.
  258.         New hosts ask for both the new and old (IP address) resource
  259.         records. Older DNS servers will not have the new resource record
  260.         type, and will therefore respond with only IP address
  261.         information. Updated DNS servers will have the new resource
  262.         record information for the requested DNS name only if the
  263.         associated host has been updated (otherwise the updated DNS
  264.         server again will respond with an IP address).
  265.  
  266.         Hosts and/or applications which do not use DNS operate in a
  267.         similar method. For example, suppose that local name to address
  268.         records are maintained in host table entries on each local
  269.         workstation. When a workstation is updated to be able to run
  270.         Internet applications over CLNP, then the host table on the host
  271.         may also be updated to contain updated NSAP addresses for other
  272.         hosts which have also been updated. The associated entries for
  273.         non-updated hosts would continue to contain IP addresses. Thus,
  274.         again when an updated host wants to initiate communication with
  275.         another host, it would look up the associated Internet address in
  276.         the normal manner. If the address returned is a normal 32-bit IP
  277.         address, then the host would initiate a request using an Internet
  278.         application over TCP (or UDP) over IP (as at present). If the
  279.         returned address is a longer NSAP address, then the host would
  280.         initiate a request using an Internet application over TCP (or
  281.         UDP) over CLNP.
  282.  
  283.  
  284.         4 Running TCP and UDP Over CLNP
  285.  
  286.         TCP is run directly on top of CLNP (i.e., the TCP packet is
  287.         encapsulated directly inside a CLNP packet - the TCP header
  288.         occurs directly following the CLNP header). Use of TCP over CLNP
  289.         is straightforward, with the only non-trivial issue being how to
  290.         generate the TCP pseudo-header (for use in generating the TCP
  291.         checksum).
  292.  
  293.         Note that TUBA runs TCP over CLNP on an end-to-end basis (for
  294.         example, there is no intention to translate CLNP packets into IP
  295.         packets). This implies that only "consenting updated systems"
  296.         will be running TCP over CLNP; which in turn implies that, for
  297.         purposes of generating the TCP pseudoheader from the CLNP header,
  298.         backward compatibility with existing systems is not an issue.
  299.         There are therefore several options available for how to generate
  300.         the pseudoheader. The pseudoheader could be set to all zeros
  301.         (implying that the TCP header checksum would only be covering the
  302.         TCP header). Alternatively, the pseudoheader could be calculated
  303.         from the CLNP header. For example, the "source address" in the
  304.         TCP pseudoheader could be replaced with two bytes of zero plus a
  305.         two byte checksum run on the source NSAP address length and
  306.         address (and similarly for the destination address); the
  307.         "protocol" could be replaced by the destination address selector
  308.         value; and the "TCP Length" could be calculated from the CLNP
  309.  
  310.  
  311.         Callon                                                    [Page 5]
  312.  
  313.  
  314.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  315.  
  316.  
  317.         packet in the same manner that it is currently calculated from
  318.         the IP packet. The details of how the pseudoheader is composed is
  319.         for further study.
  320.  
  321.         UDP is transmitted over CLNP in the same manner. In particular,
  322.         the UDP packet is encapsulated directly inside a CLNP packet.
  323.         Similarly, the same options are available for the UDP pseudo-
  324.         header as for the TCP pseudoheader.
  325.  
  326.  
  327.         5 Updates to the Domain Name Service
  328.  
  329.         TUBA requires that a new DNS resource record entry type
  330.         ("long-address") be defined, to store longer Internet (i.e.,
  331.         NSAP) addresses. This resource record allows mapping from DNS
  332.         names to NSAP addresses, and will contain entries for systems
  333.         which are able to run Internet applications, over TCP or UDP,
  334.         over CLNP.
  335.  
  336.         The presence of a "long-address" resource record for mapping a
  337.         particular DNS name to a particular NSAP address can be used to
  338.         imply that the associated system is an updated Internet host.
  339.         This specifically does  not imply that the system is capable of
  340.         running OSI protocols for any other purpose. Also, the NSAP
  341.         address used for running Internet applications (over TCP or UDP
  342.         over CLNP) does not need to have any relationship with other NSAP
  343.         addresses which may be assigned to the same host. For example, a
  344.         "dual stack" host may be able to run Internet applications over
  345.         TCP over CLNP, and may also be able to run OSI applications over
  346.         TP4 over CLNP. Such a host may have a single NSAP address
  347.         assigned (which is used for both purposes), or may have separate
  348.         NSAP addresses assigned for the two protocol stacks. The
  349.         "long-address" resource record, if present, may be assumed to
  350.         contain the correct NSAP address for running Internet applications
  351.         over CLNP, but may not be assumed to contain the correct NSAP
  352.         address for any other purpose.
  353.  
  354.         The backward translation (from NSAP address to DNS name) is
  355.         facilitated by definition of an associated resource record. This
  356.         resource record is known as "long-in-addr.arpa", and is used in a
  357.         manner analogous to the existing "in-addr.arpa".
  358.  
  359.         Updated Internet hosts, when initiating communication with
  360.         another host, need to know whether that host has been updated.
  361.         The host will request the address-class "internet address",
  362.         entry-type "long-address" from its local DNS server. If the
  363.         local DNS server has not yet been updated, then the long address
  364.         resource record will not be available, and an error response will
  365.         be returned. In this case, the updated hosts must then ask for
  366.         the regular Internet address. This allows updated hosts to be
  367.         deployed in environments in which the DNS servers have not yet
  368.         been updated.
  369.  
  370.         An updated DNS server, if asked for the long-address
  371.  
  372.  
  373.         Callon                                                    [Page 6]
  374.  
  375.  
  376.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  377.  
  378.  
  379.         corresponding to a particular DNS name, does a normal DNS search
  380.         to obtain the information. If the long-address corresponding to
  381.         that name is not available, then the updated DNS server will
  382.         return the resource record type containing the normal 32-bit IP
  383.         address (if available). This allows more efficient operation
  384.         between updated hosts and old hosts in an environment in which
  385.         the DNS servers have been updated.
  386.  
  387.         Interactions between DNS servers can be done over either IP or
  388.         CLNP, in a manner analogous to interactions between hosts. DNS
  389.         servers currently maintain entries in their databases which allow
  390.         them to find IP addresses of other DNS servers. These can be
  391.         updated to include a combination of IP addresses and NSAP
  392.         addresses of other servers. If an NSAP address is available, then
  393.         the communication with the other DNS server can use CLNP,
  394.         otherwise the interaction between DNS servers uses IP. Initially,
  395.         it is likely that all communication between DNS servers will use
  396.         IP (as at present). During the migration process, the DNS servers
  397.         can be updated to communicate with each other using CLNP.
  398.  
  399.  
  400.         6 Other Technical Details
  401.  
  402.         6.1 When 32-Bit IP Addresses Fail
  403.  
  404.         Eventually, the IP address space will become inadequate for
  405.         global routing and addressing. At this point, the remaining older
  406.         (not yet updated) IP hosts will not be able to interoperate
  407.         directly over the global Internet. This time can be postponed by
  408.         careful allocation of IP addresses and use of "Classless
  409.         Inter-Domain Routing" (CIDR [3]), and if necessary by
  410.         encapsulation (either of IP in IP, or IP in CLNP). In addition,
  411.         the number of hosts affected by this can be minimized by
  412.         aggressive deployment of updated software based on TUBA.
  413.  
  414.         When the IP address space becomes inadequate for global routing
  415.         and addressing, for purposes of IP addressing the Internet will
  416.         need to be split into "IP address domains". 32-bit IP addresses
  417.         will be meaningful only within an address domain, allowing the
  418.         old IP hosts to continue to be used locally. For communications
  419.         between domains, there are two possibilities: (i) The user at an
  420.         old system can use application layer relays (such as mail relays
  421.         for 822 mail, or by Telnetting to an updated system in order to
  422.         allow Telnet or FTP to a remote system in another domain); or
  423.         (ii) Network Address Translation can be used [4].
  424.  
  425.         6.2 Applications which use IP Addresses Internally
  426.  
  427.         There are some application protocols (such as FTP and NFS) which
  428.         pass around and use IP addresses internally. Migration to a
  429.         larger address space (whether based on CLNP or other protocol)
  430.         will require either that these applications be limited to local
  431.         use (within an "IP address domain" in which 32-bit IP addresses
  432.         are meaningful) or be updated to either: (i) Use larger network
  433.  
  434.  
  435.         Callon                                                    [Page 7]
  436.  
  437.  
  438.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  439.  
  440.  
  441.         addresses instead of 32-bit IP addresses; or (ii) Use some other
  442.         globally-significant identifiers, such as DNS names.
  443.  
  444.         6.3 Updated Hosts in IP-Only Environments
  445.  
  446.         There may be some updated Internet hosts which are deployed in
  447.         networks that do not yet have CLNP service, or where CLNP service
  448.         is available locally, but not to the global Internet. In these
  449.         cases, it will be necessary for the updated Internet hosts to
  450.         know to initially send all Internet traffic (or all non-local
  451.         traffic) using IP, even when the remote system also has been
  452.         updated. There are several ways that this can be accomplished,
  453.         such as: (i) The host could contains a manual configuration
  454.         parameter controlling whether to always use IP, or to use IP or
  455.         CLNP depending upon remote address; (ii) The DNS resolver on the
  456.         host could be "lied to" to believe that all remote requests are
  457.         supposed to go to some particular server, and that server could
  458.         intervene and change all remote requests for long-addresses into
  459.         requests for normal IP addresses.
  460.  
  461.         6.4 Local Network Address Translation
  462.  
  463.         Network Address Translation (NAT [4]) has been proposed as a
  464.         means to allow global communication between hosts which use
  465.         locally-significant IP addresses. NAT requires that IP addresses
  466.         be mapped at address domain boundaries, either to globally
  467.         significant addresses, or to local addresses meaningful in the
  468.         next address domain along the packet's path. It is possible to
  469.         define a version of NAT which is "local" to an addressing domain,
  470.         in the sense that (locally significant) IP packets are mapped to
  471.         globally significant CLNP packets before exiting a domain, in a
  472.         manner which is transparent to systems outside of the domain.
  473.  
  474.         NAT allows old systems to continue to be used globally without
  475.         application gateways, at the cost of significant additional
  476.         complexity and possibly performance costs (associated with
  477.         translation or encapsulation of network packets at IP address
  478.         domain boundaries). NAT does not address the problem of
  479.         applications which pass around and use IP addresses internally.
  480.  
  481.         The details of Network Address Translation is outside of the
  482.         scope of this document.
  483.  
  484.         6.5 Streamlining Operation of CLNP
  485.  
  486.         CLNP contains a number of optional and/or variable length fields.
  487.         For example, CLNP allows addresses to be any integral number of
  488.         bytes up to 20 bytes in length. It is proposed to "profile" CLNP
  489.         in order to allow streamlining of router operation. For example,
  490.         this might involve specifying that all Internet hosts will use an
  491.         NSAP address of precisely 20 bytes in length, and may specify
  492.         which optional fields (if any) will be present in all CLNP
  493.         packets. This can allow all CLNP packets transmitted by Internet
  494.  
  495.  
  496.  
  497.         Callon                                                    [Page 8]
  498.  
  499.  
  500.         RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992
  501.  
  502.  
  503.         hosts to use a constant header format, in order to speed up
  504.         header parsing in routers. The details of the Internet CLNP
  505.         profile is for further study.
  506.  
  507.  
  508.         7 References
  509.  
  510.         [1]    "The IAB Routing and Addressing Task Force: Summary
  511.                Report", work in progress.
  512.  
  513.         [2]    "Protocol for Providing the Connectionless-Mode Network
  514.                Service", ISO 8473, 1988.
  515.  
  516.         [3]    "Supernetting: An Address Assignment and Aggregation
  517.                Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, March 
  518.                1992.
  519.  
  520.         [4]    "Extending the IP Internet Through Address Reuse", Paul
  521.                Tsuchiya, December 1991.
  522.  
  523.  
  524.         8 Security Considerations
  525.  
  526.         Security issues are not discussed in this memo.
  527.  
  528.  
  529.         9 Author's Address
  530.  
  531.         Ross Callon
  532.         Digital Equipment Corporation
  533.         550 King Street, LKG 1-2/A19
  534.         Littleton, MA  01460-1289
  535.  
  536.         Phone: 508-486-5009
  537.  
  538.         Email: Callon@bigfut.lkg.dec.com
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.         Callon                                                    [Page 9]
  560.  
  561.  
  562.